JBoss Community Archive (Read Only)

Errai

Errai JPA

Starting with Errai 2.1, Errai implements a subset of JPA 2.0. With Errai JPA, you can store and retrieve entity objects on the client side, in the browser's local storage. This allows the reuse of JPA-related code (both entity class definitions and procedural logic that uses the EntityManager) between client and server.

Errai JPA implements the following subset of JPA 2.0:

It's all client-side

Errai JPA is a declarative, typesafe interface to the web browser's localStorage object. As such it is a client-side implementation of JPA. Objects are stored and fetched from the browser's local storage, not from the JPA provider on the server side.

Getting Started

Compile-time dependency

To use Errai JPA, you must include it on the compile-time classpath. If you are using Maven for your build, add this dependency:

    <dependency>
      <groupId>org.jboss.errai</groupId>
      <artifactId>errai-jpa-client</artifactId>
      <version>${errai.version}</version>
    </dependency>

If you are not using Maven for dependency management, add errai-jpa-client-version.jar, Hibernate 4.1.1, and Google Guava for GWT 12.0 to your compile-time classpath.

GWT Module Descriptor

Once you have Errai JPA on your classpath, ensure your application inherits the GWT module as well. Add this line to your application's *.gwt.xml file:

   <inherits name="org.jboss.errai.jpa.JPA"/>

META-INF/persistence.xml

Errai ignores META-INF/persistence.xml for purposes of client-side JPA. Instead, Errai scans all Java packages that are part of your GWT modules for classes annotated with @Entity. This allows you the freedom of defining a persistence.xml that includes both shared entity classes that you use on the client and the server, plus server-only entities that are defined in a server-only package.

Declaring an Entity Class

Classes whose instances can be stored and retrieved by JPA are called entities. To declare a class as a JPA entity, annotate it with @Entity.

JPA requires that entity classes conform to a set of rules. These are:

  • The class must have an ID attribute

  • The class must have a public or protected constructor that takes no arguments

  • The class must be public and nonfinal

  • No methods or persistent fields of the class may be final

  • The class must be a top-level type (not a nested or inner class)

Here is an example of a valid entity class with an ID attribute (id) and a String-valued persistent attribute (name):

@Entity
public class Genre {

  @Id @GeneratedValue
  private int id;

  private String name;

  // This constructor is used by JPA
  public Genre() {}

  // This constructor is not used by JPA
  public Genre(String name) {
    this();
    this.name = name;
  }


  // These getter and Setter methods are optional:

  public int getId() { return id; }
  public void setId(int id) { this.id = id; }

  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
}

Entity Attributes

The state of fields and JavaBeans properties of entities are generally persisted with the entity instance. These persistent things are called attributes.

JPA Attributes are subdivided into two main types: singular and plural. Singular attributes are scalar types like Integer or String. Plural attributes are collection values, such as List<Integer> or Set<String>.

The values of singular attributes (and the elements of plural attributes) can be of any application-defined entity type or a JPA Basic type. The JPA basic types are all of the Java primitive types, all boxed primitives, enums, BigInteger, BigDecimal, String, Date (java.util.Date or java.sql.Date), Time, and Timestamp.

You can direct JPA to read and write your entity's attributes by direct field access or via JavaBeans property access methods (that is, "getters and setters"). Direct field access is the default. To request property access, annotate the class with @Access(AccessType.PROPERTY). If using direct field access, attribute-specific JPA annotations should be on the fields themselves; when using property access, the attribute-specific annotations should be on the getter method for that property.

ID Attributes and Auto-Generated Identifiers

Each entity class must have exactly one ID attribute. The value of this attribute together with the fully-qualified class name uniquely identifies an instance to the entity manager.

ID values can be assigned by the application, or they can be generated by the JPA entity manager. To declare a generated identifier, annotate the field with @GeneratedValue. To declare an application-assigned identifier, leave off the @GeneratedValue annotation.

Generated identifier fields must not be initialized or modified by application code. Application-assigned identifier fields must be initialized to a unique value before the entity is persisted by the entity manager, but must not be modified afterward.

Single-valued Attributes

By default, every field of a JPA basic type is a persistent attribute. If a basic type field should not be presistent, mark it with transient or annotate it with @Transient.

Single-valued attributes of entity types must be annotated with @OneToOne or @ManyToOne.

Single-valued types that are neither entity types nor JPA Basic types are not presently supported by Errai JPA. Such attributes must be marked transient.

Here is an example of an entity with single-valued basic attributes and a single-valued relation to another entity type:

@Entity
public class Album {

  @GeneratedValue
  @Id
  private Long id;

  private String name;

  @ManyToOne
  private Artist artist;

  private Date releaseDate;

  private Format format;

  public Long getId() { return id; }
  public void setId(Long id) { this.id = id; }

  public String getName() { return name; }
  public void setName(String name) { this.name = name; }

  public Artist getArtist() { return artist; }
  public void setArtist(Artist artist) { this.artist = artist; }

  public Date getReleaseDate() { return releaseDate; }
  public void setReleaseDate(Date releaseDate) { this.releaseDate = releaseDate; }

  public Format getFormat() { return format; }
  public void setFormat(Format format) { this.format = format; }
}

Plural (collection-valued) Attributes

Collection-valued types Collection<T>, Set<T>, and List<T> are supported. JPA rules require that all access to the collections are done through the collection interface method; never by specific methods on an implementation.

The element type of a collection attribute can be a JPA basic type or an entity type. If it is an entity type, the attribute must be annotated with @OneToMany or @ManyToMany.

Here is an example of an entity with two plural attributes:

@Entity
public class Artist {

  @Id
  private Long id;

  private String name;

  // a two-way relationship (albums refer back to artists)
  @OneToMany(mappedBy="artist", cascade=CascadeType.ALL)
  private Set<Album> albums = new HashSet<Album>();

  // a one-way relationship (genres don't reference artists)
  @OneToMany(cascade={CascadeType.PERSIST, CascadeType.MERGE})
  private Set<Genre> genres = new HashSet<Genre>();

  public Long getId() { return id; }
  public void setId(Long id) { this.id = id; }

  public String getName() { return name; }
  public void setName(String name) { this.name = name; }

  public Set<Album> getAlbums() { return albums; }
  public void setAlbums(Set<Album> albums) { this.albums = albums; }

  public Set<Genre> getGenres() { return genres; }
  public void setGenres(Set<Genre> genres) { this.genres = genres; }
}

Entity Lifecycle States

Cascade Rules

When an entity changes state (more on this later), that state change can be cascaded automatically to related entity instances. By default, no state changes are cascaded to related entities. To request cascading of entity state changes, use the cascade attribute on any of the relationship quantifiers @OneToOne, @ManyToOne, @OneToMany, and @ManyToMany.

CascadeType value

Description

PERSIST

Persist the related entity object(s) when this entity is persisted

MERGE

Merge the attributes of the related entity object(s) when this entity is merged

REMOVE

Remove the related entity object(s) from persistent storage when this one is removed

REFRESH

Not applicable in Errai JPA

DETACH

Detach the related entity object(s) from the entity manager when this object is detached

ALL

Equivalent to specifying all of the above

For an example of specifying cascade rules, refer to the Artist example above. In that example, the cascade type on albums is ALL. When a particular Artist is persisted or removed, detached, etc., all of that artist's albums will also be persisted or removed, or detached correspondingly. However, the cascade rules for genres are different: we only specify PERSIST and MERGE. Because a Genre instance is reusable and potentially shared between many artists, we do not want to remove or detach these when one artist that references them is removed or detached. However, we still want the convenience of automatic cascading persistence in case we persist an Artist which references a new, unmanaged Genre.

Obtaining an instance of EntityManager

The entity manager provides the means for storing, retrieving, removing, and otherwise affecting the lifecycle state of entity instances.

To obtain an instance of EntityManager on the client side, use Errai IoC (or CDI) to inject it into any client-side bean:

@EntryPoint
public class Main {
  @Inject EntityManager em;
}

Storing and Updating Entities

To store an entity object in persistent storage, pass that object to the EntityManager.persist() method. Once this is done, the entity instance transitions from the new state to the managed state.

If the entity references any related entities, these entities must be in the managed state already, or have cascade-on-persist enabled. If neither of these criteria are met, an IllegalStateException will be thrown.

See an example in the following section.

Fetching Entities by ID

If you know the unique ID of an entity object, you can use the EntityManager.find() method to retrieve it from persistent storage. The object returned from the find() method will be in the managed state.

Example:

    // make it
    Album album = new Album();
    album.setArtist(null);
    album.setName("Abbey Road");
    album.setReleaseDate(new Date(-8366400000L));

    // store it
    EntityManager em = getEntityManager();
    em.persist(album);
    em.flush();
    em.detach(album);
    assertNotNull(album.getId());

    // fetch it
    Album fetchedAlbum = em.find(Album.class, album.getId());
    assertNotSame(album, fetchedAlbum);
    assertEquals(album.toString(), fetchedAlbum.toString());

Removing Entities from Persistent Storage

To remove a persistent managed entity, pass it to the EntityManager.remove() method. As the cascade rules specify, related entities will also be removed recursively.

Once an entity has been removed and the entity manager's state has been flushed, the entity object is unmanaged and back in the new state.

Clearing all Local Storage

Errai's EntityManager class provides a removeAll() method which removes everything from the browser's persistent store for the domain of the current webpage.

This method is not part of the JPA standard, so you must down-cast your client-side EntityManager instance to ErraiEntityManager. Example:

@EntryPoint
public class Main {

  @Inject EntityManager em;

  void resetJpaStorage() {
    ((ErraiEntityManager) em).removeAll();
  }
}

Detaching Entity Instances from the Entity Manager

For every entity instance in the managed state, changes to the attribute values of that entity are persisted to local storage whenever the entity manager is flushed. To prevent this automatic updating from happening, you can detach an entity from the entity manager. When an instance is detached, it is not deleted. All information about it remains in persistent storage. The next time that entity is retrieved, the entity manager will create a new and separate managed instance for it.

To detach one particular object along with all related objects whose cascade rules say so, call EntityManager.detach() and pass in that object.

To detach all objects from the entity manager at once, call EntityManager.detachAll().

Testing if an Entity is in the Managed State

To check if a given object is presently managed by the entity manager, call EntityManager.contains() and pass in the object of interest.

Named Queries

To retrieve one or more entities that match a set of criteria, Errai JPA allows the use of JPA named queries. Named queries are declared in annotations on entity classes.

Declaring Named Queries

Queries in JPA are written in the JPQL language. As of Errai 2.1, Errai JPA does not support all JPQL features. Most importantly, implicit and explicit joins in queries are not yet supported. Queries of the following form generally work:

SELECT et FROM EntityType et WHERE [expression with constants, named parameters and attributes of et] ORDER BY et.attr1 [ASC|DESC], et.attr2 [ASC|DESC]

Here is how to declare a JPQL query on an entity:

@NamedQuery(name="selectAlbumByName", query="SELECT a FROM Album a WHERE a.name=:name")
@Entity
public class Album {
  ... same as before ...
}

To declare more than one query on the same entity, wrap the @NamedQuery annotations in @NamedQueries like this:

@NamedQueries({
  @NamedQuery(name="selectAlbumByName", query="SELECT a FROM Album a WHERE a.name = :name"),
  @NamedQuery(name="selectAlbumsAfter", query="SELECT a FROM Album a WHERE a.releaseDate >= :startDate")
})
@Entity
public class Album {
  ... same as before ...
}

Executing Named Queries

To execute a named query, retrieve it by name and result type from the entity manager, set the values of its parameters (if any), and then call one of the execution methods getSingleResult() or getResultList().

Example:

    TypedQuery<Album> q = em.createNamedQuery("selectAlbumByName", Album.class);
    q.setParameter("name", "Let It Be");
    List<Album> fetchedAlbums = q.getResultList();

Entity Lifecycle Events

To receive a notification when an entity instance transitions from one lifecycle state to another, use an entity lifecycle listener.

These annotations can be applied to methods in order to receive notifications at certain points in an entity's lifecycle. These events are delivered for direct operations initiated on the EntityManager as well as operations that happen due to cascade rules.

Annotation

Meaning

@PrePersist

The entity is about to be persisted or merged into the entity manager.

@PostPersist

The entity has just been persisted or merged into the entity manager.

@PreUpdate

The entity's state is about to be captured into the browser's localStorage.

@PostUpdate

The entity's state has just been captured into the browser's localStorage.

@PreRemove

The entity is about to be removed from persistent storage.

@PostRemove

The entity has just been removed from persistent storage.

@PostLoad

The entity's state has just been retrieved from the browser's localStorage.

JPA lifecycle event annotations can be placed on methods in the entity type itself, or on a method of any type with a public no-args constructor.

To receive lifecycle event notifications directly on the affected entity instance, create a no-args method on the entity class and annotate it with one or more of the lifecycle annotations in the above table.

For example, here is a variant of the Album class where instances receive notification right after they are loaded from persistent storage:

@Entity
public class Album {

  ... same as before ...

  @PostLoad
  public void postLoad() {
    System.out.println("Album " + getName() + " was just loaded into the entity manager");
  }
}

To receive lifecycle methods in a different class, declare a method that takes one parameter of the entity type and annotate it with the desired lifecycle annotations. Then name that class in the @EntityListeners annotation on the entity type.

The following example produces the same results as the previous example:

@Entity
@EntityListeners(StandaloneLifecycleListener.class)
public class Album {

  ... same as always ...

}

public class StandaloneLifecycleListener {

  @PostLoad
  public void albumLoaded(Album a) {
  public void postLoad() {
    System.out.println("Album " + a.getName() + " was just loaded into the entity manager");
  }
}

JPA Metamodel

Errai captures structural information about entity types at compile time and makes them available in the GWT runtime environment. The JPA metamodel includes methods for enumerating all known entity types and enumerating the singular and plural attributes of those types. Errai extends the JPA 2.0 Metamodel by providing methods that can create new instances of entity classes, and read and write attribute values of existing entity instances.

As an example of what is possible, this functionality could be used to create a reusable UI widget that can present an editable table of any JPA entity type.

To access the JPA Metamodel, call the EntityManager.getMetamodel() method. For details on what can be done with the stock JPA metamodel, see the API's javadoc or consult the JPA specification.

Errai Extensions to JPA Metamodel API

Wherever you obtain an instance of SingularAttribute from the metamodel API, you can down-cast it to ErraiSingularAttribute. Likewise, you can down-cast any PluralAttribute to ErraiPluralAttribute.

In either case, you can read the value of an arbitrary attribute by calling ErraiAttribute.get() and passing in the entity instance. You can set any attribute's value by calling ErraiAttribute.set(), passing in the entity instance and the new value.

In addition to get() and set(), ErraiPluralAttribute also has the createEmptyCollection() method, which creates an empty collection of the correct interface type for the given attribute.

JPA Features Not Implemented in Errai 2.4

The following features are not yet implemented, but could conceivably be implemented in a future Errai JPA release:

  • Flush modes other than immediate

  • Transactions, including EntityManager.getTransaction()

  • In named queries:

    • Joins and nested attribute paths (a.b.c) do not yet work, although single-step attribute paths (a.b) do.

    • The SELECT clause must specify exactly one entity type. Selection of individual attributes is not yet implemented.

  • Embedded collections

  • Compound identifiers (presently, only basic types are supported for entity IDs)

  • EntityManager.refresh() to pick up changes made in localStorage from a different browser window/tab.

  • Criteria Queries

    • The generated static Metamodel

  • The @PersistenceContext annotation currently has no effect in client-side code (use @Inject instead)

The following may never be implemented due to limitations and restrictions in the GWT client-side environment:

  • EntityManager.createQuery(String, ...) (that is, unnamed queries) are impractical because JPQL queries are parsed at compile time, not in the browser.

  • EntityManager.createNativeQuery(String, ...) don't make sense because the underlying database is just a hash table. It does not have a query language.

  • Persistent attributes of type java.util.Calendar because the Calendar class is not in GWT's JRE emulation library.

Other Caveats for Errai 2.1 JPA

We hope to remedy these shortcomings in a future release.

  • In Dev Mode, changes to entity classes are not discovered on page refresh. You need to restart Dev Mode.

  • The local data stored in the browser is not encrypted

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-10 12:34:55 UTC, last content change 2013-12-06 22:25:27 UTC.